Handles #8

Tried pushing to your branch but was rejected 😕

Tried pushing to your branch but was rejected 😕

I guess I didn't make it editable... will I open new PR or will you make a PR against my repo 😂

If you're OK to make it editable, there's a box you can check on this page to allow maintainers to edit the PR 🙂

Huh. Maybe once it gets out of draft? Weird.

I just changed it to draft hoping the option would appear

Oh OK. Can you try to open a new PR then? It will be easier than me sending a PR to your fork so that you can send it back... 😅

I think it's because the fork is in organisation...

edit: yep, now should work

Nice, thanks 🙂 We should now document the feature. We can probably document each item in the rendering.default_config dict. Or we could refer to https://mkdocstrings.github.io/python/usage/configuration/general/ and the other configuration sections since they work the same way 🤷

After your changes make check (ruff) complains about unused "noqa" directives.

I've added a TypedDict for the configuration to allow docstr for each entry separately. I think it's clearer than a single docstr for all entries

Add quotes to type expression in typing.cast()

srsly 🤣

TC001 Move application import griffe2md.rendering into a type-checking block

AFAIK you shouldn't mix TYPE_CHECKING and from __future__ import annotations

src/griffe2md/rendering.py:33: error: Cannot find implementation or library stub for module named "griffe.dataclasses" [import-not-found]
src/griffe2md/rendering.py:33: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
F

griffe.dataclasses?

Add quotes to type expression in typing.cast()

Yeah that removes the need for importing the symbols.

AFAIK you shouldn't mix TYPE_CHECKING and from future import annotations

Why? Until our lowest supported version is Python 3.14 (PEP 649), I think it's reasonable.

griffe.dataclasses?

Right this should be griffe directly.

Add quotes to type expression in typing.cast()

Yeah that removes the need for importing the symbols.

AFAIK you shouldn't mix TYPE_CHECKING and from __future__ import annotations

Why? Until our lowest supported version is Python 3.14 (PEP 649), I think it's reasonable.

They pretty much handle the same cases, type/lazy and potential recursive imports. Shouldn't one suffice?

Future annotations let you do this kind of things while waiting for PEP 649:

class A:
    @staticmethod
    def create_a() -> A: ...

def func() -> A:
    return A()


class A:
    pass

So do you want to merge, add something or you want me to figure what other entries do and update the docstrs?

If you have the capacity, documenting the other options would be great, yes, otherwise I'll get to it eventually 🙂

I've skipped a few fields, most of them are really self-explanatory, but I couldn't figure out load_external_modules and members